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(57) To overcome the lack of support in time- 
sharing and uniprocessor operating systems 
such as the UNIX® operating system for real- 
time and multiprocessor applications, there is 
provided an asynchronous inter-process com- 
munications capability that can be grafted onto 
the operating systems. Communicating proces- 
ses (100, 103) communicate via datagram mes- 
sages through logical asynchronous 
inter-process communications links (110) each 
having a synchronous segment (101) and an 
asynchronous segment (102). The links include 
a message-serving hub process (11) that com- 
municates in a synchronous, buffer and 
semaphore based, manner with processes (100) 
that are message senders, and communicates 
in an asynchronous, queue and signals based, 
manner with processes (103) that are message 
destinations. The hub process may be im- 
plemented at any process level of the operating 
system. 
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Technical Field 

This invention relates generally to computer op- 
erating systems, and relates specifically to inter-proc- 
ess communication arrangements of operating sys- 
tems. 

Background of the Invention 

Inter-process communication arrangements of 
computer operating systems come in two basic vari- 
eties: synchronous and asynchronous. Synchronous 
inter-process communications are those that require 
a common occurrence, such as common timing, a 
predef ined relationship, or in-step operation, in order 
for two or more processes to communicate. Con- 
versely, asynchronous inter-process communications 
are those that occur without a regular or predictable 
time relationship or correlation between the commu- 
nicating processes. Another way of viewing the differ- 
ence between synchronous and asynchronous inter- 
process communications is that synchronous com- 
munications require the transmitting process to coor- 
dinate its transmissions in time with reception by the 
receiving process or processes, whereas asynchron- 
ous communications allow the transmitting and re- 
ceiving processes to transmit and receive indepen- 
dently in time of each other's operations. 

On one hand, operating systems designed to sup- 
port uniprocessor time-sharing operations, such as 
the UNIX® operating system, generally implement 
synchronous intej^pj^cess communications. On the 
other hand,< giuTHprocessy and real-time operations 
typically require asynchronous inter-process commu- 
nications for their support. Synchronous communica- 
tions arrangements are generally difficult to use with 
a multiplicity of processes and too prone to deadlock 
to provide effective support for multiprocessor and 
real-time operations. 

Unfortunately, this requirement undesirably lim- 
its the uses for popular operating systems, such as 
the UNIX system, that do not provide effective asyn- 
chronous inter-process communications capabilities. 
The advantages of such popular operating systems 
include a large supply of designers experienced in 
their use, who may be readily drawn upon to staff new 
projects and to get these projects substantively under 
way beyond the initial start-up, learning, curve. The 
advantages further include a large body of existing 
programs that may be drawn upon as a library and 
that may be re-used in new projects without having to 
be designed anew. 

Of course, conventional operating systems often 
may be redesigned to support real-time or multipro- 
cessor operations and to include asynchronous inter- 
process communications mechanisms. But conven- 
tionally, such redesign effectively results in a new op- 
erating system that destroys the above-enumerated 



advantages of the system on which it is based. An il- 
lustrative example of such a redesigned operating 
system is the UNIX-RTR operating system, which is 
a UN IX- based system that supports real-time appli- 

5 cations such as telephony switching. 

Consequently, what the art requires is an asyn- 
chronous inter- process communications mechanism 
that can be grafted onto an operating system, such as 
the UNIX system, without adversely affecting any of 

10 its conventional interfaces and operational character- 
istics. However, the standard operating system facili- 
ties provided by the UNIX operating system and its 
clones and derivatives make this difficult to achieve. 
The operating systems' inter- process-related system 

f 5 calls (e.g., shared memory, semaphores, inter-proc- 
ess messages and signals) are synchronous in nature 
and do not lend themselves to the support of asyn- 
chronous communication schemes. In addition the 
UNIX-type operating systems do not normally provide 

20 a facility for inhibiting process switches. This creates 
the possibility of multiple processes accessing 
shared memory simultaneously, thereby greatly lim- 
iting the usefulness of shared memory. 

25 Summary of the Invention 

This invention is directed to solving the problems 
and meeting the needs of the prior art According to 
the invention, there is provided an asynchronous in- 

30 ter-process communications arrangement that may 
be grafted onto an operating system (for example, 
onto the UNIX operating system) in order to overcome 
the limited support for real-time and multiprocessor 
applications. The asynchronous inter-process com- 

35 munications arrangement comprises a synchronous 
communications path segment for communicating 
with a first process, such as the message-sending 
process, of a pair of communicating processes within 
a single processor, an asynchronous communications 

40 path segment for communicating with a second proc- 
ess of the pair, and an arrangement, such as a pro- 
cedure, for interconnecting the synchronous and the 
asynchronous communications path segments to 
form a communications path extending between the 

45 processes of the pair. 

Illustratively, the synchronous segment is sema- 
phore-based. It utilizes a buffer implemented in 
shared memory and shared by the plurality of mes- 
sage-sending processes. Access to the buffer by the 

so sending processes and the interconnecting proce- 
dure is serialized by a semaphore having three states 
or values. Also illustratively, the asynchronous seg- 
ment is buffer-based. It utilizes circular buffers imple- 
mented in shared memory, a different one for each 

55 message-receiving process. A write pointer to each 
buffer is controlled by the interconnecting procedure, 
while a read pointer to each buffer is controlled by the 
corresponding message receiving process. The pro- 
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cedure notifies message-receiving processes of 
presence of a message via a signals facility. 

As required by the art, the invention provides an 
asynchronous inter-process communications mecha- 
nism that can be grafted onto an operating system 
without adversely affecting any of the operating sys- 
tem's conventional interfaces and operational charac- 
teristics. It thus provides support for both real-time 
and multiprocessor applications without destroying 
existing characteristics, features or advantages of the 
existing operating system. It is simple to implement; 
illustratively, it is implementable as just another proc- 
ess. Furthermore, it may be incorporated into any 
process level of the operating system. 

These and other advantages and features of the 
invention will become apparent from the following de- 
scription of an illustrative embodiment of the invention 
taken together with the drawing. 

Brief Description of the Drawing 

FIG. 1 is a logical diagram of a computer that in- 
corporates an illustrative embodiment of the in- 
vention; 

FIG. 2 is a block diagram of an inter-process com- 
munications link of the computer of FIG. 1; 
FIG. 3 is a block diagram of synchronous data- 
structures-and-functions block of a hub function 
of the link of FIG. 2; 

FIG. 4 is a flow diagram of a synchronous proce- 
dure of a sending process of the link of FIG. 2; 
FIG. 5 is a flow diagram of a synchronous portion 
of a procedure of the hub function of the link of 
FIG. 2; 

FIG. 6 is a block diagram of asynchronous data- 
structures-and-functions block of the hub func- 
tion of the link of FIG. 2; 

FIG. 7 is a flow diagram of an asynchronous por- 
tion of the procedure of the hub function of the 
link of FIG. 2; and 

FIG. 8 is a flow diagram of an asynchronous pro- 
cedure of a receiving process of the link of FIG. 
2. 

Detailed Description 

FIG. 1 is a logical diagram of a computer 10. Com- 
puter 10 comprises one or more partitions 1-N. Com- 
puter 10 may be a multiprocessor system wherein 
each partition 1-N represents a separate processor. 
Or, computer 10 may be a uniprocessor system 
wherein partitions 1-N are merely logical groupings of 
functions or processes of the system. A uniprocessor 
system 10 need not be partitioned, i.e., it may consist 
of only a single partition. 

. Each partition 1-N includes a plurality of conven- 
tional processes 0-K, where the value of K may differ 
from partition to partition. Processes 0-K in a single 



partition 1-N may communicate with each other and 
with processes in other partitions 1-N through con- 
ventional inter-process communication arrange- 
ments provided by the operating system of their indi- 

5 vidual partition 1-N. Therefore, all existing functional- 
ity is preserved. Illustratively, either each partition 1- 
N executes its own copy of the UNIX operating sys- 
tem, or all partitions 1-N execute a common copy of 
the operating system, as is conventional. 

10 According to the invention, each partition 1-N fur- 

ther includes a hub function 11 that provides asyn- 
chronous inter-process communications capability 
among processes 0-K of that partition 1-N, and pro- 
vides such capability between processes 0-K of that 

15 partition and the processes 0-K of the other partitions 
1-N through associated one or more interface nodes 
12. The interface nodes 12 are directly interconnect- 
ed by communication paths 15. Illustratively, each 
path 15 is a conventional communication mechanism, 

20 such as a TCP/IP-protocol link on an Ethernet® LAN, 
or a serial point-to-point modem connection. Illustra- 
tively, each interface node 12 is implemented as a 
process in the corresponding partition 1-N. Imple- 
mentation of interface nodes 12 as processes en- 

25 ables hub functions 1 1 to treat inter-partition commu- 
nications, that is, communications to and from inter- 
face nodes 12, identically to intra- partition communi- 
cations between processes 0-K. 

In each partition 1-N, hub function 11 is also im- 

30 piemen ted as a process, at any one of the process 
levels provided by the operating system of that parti- 
tion 1-N. For example, in the UNIX operating system, 
hub function 11 may be implemented either as a user- 
level (application) process, or as a kernel-level proc- 

35 ess, internal to the operating system. Intermediate or 
interpreter-level (shell) process implementations may 
also be envisioned. 

As shown in FIG. 2, hub function 11 implements 
a logical asynchronous inter- process communica- 
te tions path or link 110 between each communication- 
sending process 100 and a communication-receiving 
process 103. Processes 100 and 103 are from the set 
of processes 0-K and interface nodes 12. Each inter- 
process communications link 110 is made up of two 

45 portions or segments: a synchronous inter-process 
communications segment 101 between sending proc- 
ess 100 and hub function 11, and an asynchronous in- 
ter-process communications segment 102 between 
hub function 11 and receiving process 103. A single 

so synchronous segment 101 may form a part of a plur- 
ality of inter-process communications links 110, such 
as when sending process 100 is broadcasting to a 
plurality of receiving processes 1 03. 

Hub function 11 acts as a message server be- 

55 tween sending processes 100 and receiving process- 
es 103. Hub function 11 comprises two sets of data 
structures and facilities 200 and 202, which are 
shown in FIGS. 3 and 6. respectively, and a procedure 
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201 which is diagramed in FIGS. 5 and 7. Synchron- 
ous segment 101 is implemented by a sending proc- 
ess 100 procedure which is diagramed in FIG. 4, by 
data structures and facilities 200, and the portion of 
procedure 201 which is diagramed in FIG. 5. Asyn- 
chronous segment 1 02 is implemented by the portion 
of procedure 201 which is diagramed in FIG. 7, by 
data structures and facilities 202, and by a receiving 
process 1 03 procedure which is diagramed in FIG. 8. 
Procedure 201 therefore acts as an interface be- 
tween segments 101 and 1 02 that joins the two seg- 
ments together to form link 110. 

As shown in FIG. 3, data structures and facilities 
200 comprise a message buffer 302 implemented in 
shared memory 301, and an associated semaphore 
300. Shared memory 301 is a mechanism supported 
by the standard UNIX operating system which allows 
the plurality of processes 0-K, interface nodes 12, 
and hub function 11 to map a part of their own address 
spaces into the same portion 302 of physical mem- 
ory. Semaphore facility 304 is also a mechanism sup- 
ported by the standard UNIX operating system which 
allows a read-mod rfy-write (RMW) sequence of oper- 
ations to be performed as an atomic operation on a 
memory location. Semaphore facility 304 includes 
semaphore 300 and an associated semaphore queue 
303. Semaphore 300 takes on three logical states or 
values: "0", "1", and "3". Semaphore 300 is initialized 
with a value of "3". As is conventional in the UNIX op- 
erating system, any process that attempts to perform 
an RMW sequence on semaphore 300 that would 
change the semaphore's value to a negative value is 
automatically put to sleep by the UNIX operating sys- 
tem on semaphore queue 303, and is awakened by 
the operating system only when it both (a) reaches 
the head of queue 303 and (b) execution of its previ- 
ously-attempted RMW sequence will not change the 
semaphore's value to a negative value. Semaphore 
300 implements what is conventionally referred to as 
a "critical region" around message buffer 302; it en- 
sures that only one process has access to message 
buffer 302 at any one time. 

. When a process 0-K or an interface node 12 wish- 
es to communicate with another process 0-K or an in- 
terface node 12 by means of an inter-process com- 
munications link 110, it executes the procedure of 
FIG. 4 to become sending process 100. Upon its in- 
vocation, at step 400, the procedure attempts to per- 
form an RMW sequence that decrements the value of 
semaphore 300 by two, at step 401 . The only time that 
the attempt at the RMW sequence succeeds is when 
semaphore 300 has a value of "3", which signifies that 
message buffer 302 is empty and available for use. If 
the value of semaphore 300 is "1" or"0", the RMW se- 
quence blocks or suspends because the sequence 
would reduce the value of semaphore 300 to a nega- 
tive value, and sending process 100 is put to sleep on 
queue 303, at step 402. When this sending process 



100 reaches the head of queue 303 and semaphore 
300 re-acquires a value of "3", sending process 100 
is awakened, at step 403, and it returns to step 401 
to attempt again the previously-failed RMW se- 

s quence. 

If and when the RMW sequence of step 401 suc- 
ceeds, the value of semaphore 300 becomes "1", 
which signifies that message buffer 302 is in use and 
being filled. Following its success at step 401, the 

10 procedure of FIG. 4 transfers into message buffer 302 
whatever message sending process 100 wishes to 
send, at step 404. Illustratively, the message has the 
form of a datagram. The message includes an identi- 
fier of one or more receiving processes 103 which are 

15 intended to receive the message. The procedure then 
attempts to perform an RMW sequence that decre- 
ments the value of semaphore 300 by one, at step 
405. Since steps 401 and 405 are always performed 
in the same order, this attempt never fails except in 

20 case of an error. Therefore, the value of semaphore 
300 becomes "0" at step 405, which signifies that 
message buffer 302 is in use and has been filled with 
a message. Its task is completed, and the procedure 
of FIG. 4 now returns to the point of its invocation, at 

25 step 406. 

Procedure 201 of hub function 11 starts executing 
upon initialization of its corresponding partition 1-N. 
Upon being started, at step 500 of FIG. 5, procedure 

201 reads semaphore 300, at step 501 , to determine 
30 if its value is "0", at step 502. If not, it means that a 

message is not stored in message buffer 302, and so 
procedure 201 merely returns to step 501 to await ar- 
rival of a message. Alternatively, to avoid consuming 
CPU resources, procedure 201 goes to sleep on sem- 

35 aphore 300, in a conventional manner, and is awak- 
ened when the value of semaphore 300 becomes "0". 
If the value of semaphore 300 is "0", it means that a 
message is stored in message buffer 302, and so pro- 
cedure 201 retrieves the stored message, at step 503. 

40 This frees message buffer 302 for use by another 
sending process 1 00. Procedure 201 so indicates by 
performing an RMW sequence on semaphore 300 
that increments the value of semaphore 300 by three, 
i.e., back to a value of "3". Procedure 201 then ad- 

45 vances to step 700 of FIG. 7. 

Turning to FIG. 6, data structures and facilities 

202 comprise a plurality of circular data queues 602 
implemented in shared memory 301, one queue 602 
for each process 0-K and interface node 12, i.e., one 

so for each entity that may be a receiving process 103. 

The implementation of queues 602 must be sen- 
sitive to the fact that the UNIX operating system does 
not support any mechanism for preventing process 
switches. Consequently, switches between process- 

55 es 201 and 1 03 may occur at any time, including when 
the running process is in the midst of operating on a 
queue 602. One way of dealing with this situation is 
to permit only two reference structures to a queue 
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602 —a read index and a write index- and allow each 
reference structure to be operated on exclusively by 
only one of the processes 201 and 103. Also, it must 
be ensured that all read and write operations on the 
read and write indexes are atomic operations. For ex- 
ample, on some machines, the read and write indexes 
must each be limited to a single byte in length. Ac- 
cordingly, each queue 602 comprises a plurality of en- 
tries 605, and has an associated write (W) pointer 603 
under control of procedure 201 of hub function 11 and 
a read (R) pointer 604 -under control of the corre- 
sponding receiving process 103. Procedure 201 
writes messages into queues 602. Receiving proc- 
esses 103 retrieve messages from queues 602, each 
from its own corresponding queue 602. Also included 
among data structures and facilities 202 is the con- 
ventional UNIX system signals facility 600. It is a 
mechanism by which the operating system notifies 
processes of the occurrence of asynchronous events, 
e.g., traps and interrupts. 

After it retrieves a message from message buffer 
302 in FIG. 5, procedure 201 determines from the 
message contents the identity of receiving process 
103 to which the message is addressed, at step 700. 
Procedure 201 then checks the receiving proc- 
ess* corresponding queue 602 to determine if it is full, 
at step 701 , in a conventional manner. If so, procedure 
201 discards the message, at step 703, and then re- 
turns to step 501 of FIG. 5. It is not necessary to in- 
form sending process 100 of the failure to deliver the 
message, because a datagram protocol is being used 
which does not guarantee message delivery. Under a 
datagram protocol convention, message retransmis- 
sion is the responsibility of the application. 

If procedure 201 determines at step 701 that 
queue 602 of receiving process 103 is not full, it writes 
the retrieved message into an entry 605 of that queue 
602 which is pointed to by that queue's associated W 
pointer 603, at step 705, and increments W pointer 
603, at step 706. Procedure 201 then checks whether 
this is the only message in that queue 602, i.e., 
whetherthat queue 602 had been empty, atstep 707, 
again in a conventional manner. If so, procedure 201 
causes signals facility 600 to send a signal to receiv- 
ing process 1 03 to inform it of presence of a message 
in its queue 602, at step 708. Procedure 201 then re- 
turns to step 501 of FIG. 5. 

In response to receiving a signal that was caused 
by procedure 201 to be sent at step 708, receiving 
process 103 eventually executes the procedure of 
FIG. 8. Upon its invocation, atstep 800, the procedure 
accesses the process* corresponding queue 602 and 
retrieves a message from entry 605 pointed to by that 
queue's R pointer 604, at step 801 . The procedure 
also increments R pointer 604, at step 802. The pro- 
cedure then checks whether that queue 602 is empty, 
at step 803, in a conventional manner. If not, the pro- 
cedure returns to step 801 to retrieve another mes- 



sage from that queue 602. But if queue 602 is now 
empty, the procedure clears the signal that caused its 
invocation, at step 804, and then returns to the point 
of its invocation, at step 805. The inter-process com- 

5 munication between sending and receiving process- 
es is thus completed. 

Of course, it should be understood that various 
changes and modifications to the illustrative embodi- 
ment described above will be apparent to those skil- 

10 led in the art For example, a wide range of inter-proc- 
essor communications schemes may be used -the 
described technique is independent of the inter proc- 
essor communications mechanism. Also, the multi- 
processor may be implemented as a single machine 

15 within a common cabinet, or it may be a network of 
discrete machines. Furthermore, different queueing 
data structures other than circular buffers may be 
used. Further yet, a UNIX inter-process message fa- 
cility may be substituted for semaphores or shared 

20 memory. Such changes and modifications can be 
made without departing from the spirit and the scope 
of the invention and without diminishing its attendant 
advantages. It is therefore intended that all such 
changes and modifications be covered by the follow- 

25 ing claims. 



Claims 

30 1. An inter-process communications arrangement 
comprising: 

a synchronous communications path seg- 
ment for communicating with a first process of a 
pair of communicating processes within a single 
35 processor, 

an asynchronous communications path 
segment for communicating with a second proc- 
ess of the pair, and 

means for interconnecting the synchron- 
40 ous and the asynchronous communications path 

segments to form a communications path ex- 
tending between the processes of the pair. 

2. The arrangement of claim 1 wherein 

45 the interconnecting means comprise: 

first means for communicating with the 
first process in a synchronous manner across the 
synchronous communications path segment to 
receive from the first process a communication 

so destined for the second process; and 

second means for communicating with the 
second process in an asynchronous manner 
across the asynchronous communications path 
segment to transfer the received communication 

55 to the second process. 

3. The arrangement of claim 1 wherein: 

the synchronous communications path 
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segment comprises 

a shared-memory message buffer, and 

a semaphore means for creating a critical 
region around the message buffer; and 

the asynchronous communications path 5 
segment comprises 

a shared-memory message queue having 
a read pointer and a write pointer, and 

a signals means for giving notice of pres- 
ence of a message in the queue. w 

The arrangement of claim 1 CHARACTERIZED 
IN THAT 

the arrangement is implemented using 
UNIX system facilities in a UNIX system operat- 15 
ing environment 

The arrangement of claim 1 wherein: 

the synchronous communications path in- 
cludes 20 

a message buffer for use by a plurality of 
message-sending processes, 

a semaphore associated with the mes- 
sage buffer to control access to the message buf- 
fer and having three possible states, and 25 

first operative means associated with the 
first process for performing a first operation on 
the semaphore when the semaphore is in a first 
state indicating that the buffer is available for use 
by the message-sending processes to place the 30 
semaphore in a second state thereby reserving 
the message buffer for exclusive use by the first 
process, and responsive to the reservation for 
storing a message in the message buffer and 
performing a second operation on the sema- 35 
phore to place the semaphore in a third state 
thereby freeing the message buffer for use by the 
interconnecting means; and 

the interconnecting means include 
second operative means responsive to the 40 
semaphore being in the third state for retrieving 
the stored message from the message buffer and 
performing a third operation on the semaphore to 
place the semaphore in the first state. 

45 

The arrangement of claim 1 wherein: 

the asynchronous communications path 
includes 

a plurality of message buffers each asso- 
ciated with a different message-receiving proc- so 
ess; 

means for sending a signal to a selected 
message-receiving process, and 

first operative means associated with the 
second process and responsive to receipt of a 55 
signal from the signal-sending means for retriev- 
ing a stored message from the one of the mes- 
sage buffers associated with the second proc- 



ess; and 

the interconnecting means include 
second operative means for storing a re- 
ceived message in the one of the message buf- 
fers associated with the second process and 
causing the signal-sending means to send a sig- 
nal to the second process. 

7. The arrangement of claim 1 wherein: 

the synchronous communications path in- 
cludes 

a message buffer for use by a plurality of 
message-sending processes, 

a semaphore associated with the mes- 
sage buffer to control access to the message buf- 
fer and having three possible states, and 

first operative means associated with the 
first process for performing a first operation on 
the semaphore when the semaphore is in a first 
state indicating that the buffer is available for use 
by the message-sending processes to place the 
semaphore in a second state thereby reserving 
the message buffer for exclusive use by the first 
process, and responsive to the reservation for 
storing a message in the message buffer and 
performing a second operation on the sema- 
phore to place the semaphore in a third state 
thereby freeing the message buffer for use by the 
interconnecting means; 

the interconnecting means include 

second operative means responsive to the 
semaphore being in the third state for retrieving 
thestored message from the message bufferand 
performing a third operation on the semaphore to 
place the semaphore in the first state; 

the asynchronous communications path 
includes 

a plurality of message buffers each asso- 
ciated with a different message-receiving proc- 
ess; 

means for sending a signal to a selected 
message-receiving process, and 

third operative means associated with the 
second process and responsive to receipt of a 
signal from the signal-sending means for retriev- 
ing a stored message from the one of the mes- 
sage buffers associated with the second proc- 
ess; and 

the interconnecting means further include 
fourth operative means responsive to re- 
trieval of a message by the second operative 
means for storing the retrieved message in the 
one of the message buffers associated with the 
second process and causing the signal-sending 
means to send a signal to the second process. 

8. An inter-process communications method com- 
prising the steps of: 
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synchronously communicating with a first 
process of a pair of communicating processes 
within a single processor to receive a communi- 
cation from the first process for the second proc- 
ess; and 5 

in response to receipt of the communica- 
tion, asynchronously communicating with a sec- 
ond process of the pair to transfer the received 
communication to the second process. 

10 

9. The method of claim 8 wherein 

the step of synchronously communicating 
comprises the step of 

communicating with the first process 
through a shared-memory message buffer by us- 1 5 
ing a semaphore facility to create a critical region 
around the message buffer; and 

the step of asynchronously communicat- 
ing comprises the step of 

communicating with the second process 20 
through a shared-memory message queue, hav- 
ing a read pointer and a write pointer, by using a 
signals facility to indicate to the second process 
presence of a message in the queue. 

25 

10. The method of claim 8 CHARACTERIZED IN 
THAT 

the method is implemented using UNIX 
system facilities in a UNIX system operating en- 
vironment. 30 
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(57) To overcome the lack of support in time- 
sharing and uniprocessor operating systems 
such as the UNIX® operating system for real- 
time and multiprocessor applications, there is 
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manner with processes (103) that are message 
destinations. The hub process may be im- 
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